Overview

In a typical enterprise, many architectures will be in existence at any point in time. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a big picture. Likewise, there will also be many solutions in use, or being considered for use, to meet the needs of the enterprise.

Each of these solutions and architectures does not exist in a vacuum and the Enterprise Continuum, discussed in Enterprise Continuum , provides a classification model for all related architectures and solutions. Within the Enterprise Continuum, boundaries, relationships, and ordering can be established for both solutions and architectures in order to simplify the development and management of the enterprise.

For example, any particular characteristic of architectures (e.g., time) can be used to create a "sliding scale" for this characteristic (e.g., a timeline), which can then be applied to individual architectures to create an ordered listing (e.g., architectures in chronological order, or an Architecture Roadmap). Finally, the ordered listing can then be used to drive policy and process within the enterprise (e.g., five-year architectures are developed by a particular team).

Both solutions and architectures have a set of characteristics that can be used to define what they are and how they are managed. When specifically considering architectures, there are some characteristics that relate to the architecture and others that are inherited from the solutions that the architecture is describing.

These characteristics can be used to create a partitioning model for the enterprise, showing the boundaries of individual architectures and also groupings of related architectures.

We need to partition architectures because:

• Addressing all problems within a single architecture is too complex.
• Different architectures conflict with one another (e.g., the state of the enterprise changes over time and an architecture from one time period will conflict with an architecture for a different time period).
• Different people need to work on different elements of architecture at the same time and partitions allow for specific groups of architects to own and develop specific segments of the architecture.
• Effective architecture re-use requires modular architecture segments that can be taken and incorporated into broader architectures and solutions.

However, it is difficult to present a definitive partitioning model for architecture, as each enterprise is likely to adopt a partitioning model that reflects its own operating model. An example approach to partitioning architectures into segments within the US Federal Government can be found within the Federal Enterprise Architecture Practice Guidance.¹

This chapter discusses the classification criteria that are generally applied to architectures or solutions and how these can be leveraged to partition the enterprise into a set of architectures with manageable complexity.

Characteristics of Solutions

When attempting to describe a solution, it is possible to use a number of different approaches. The following three characteristics can be used to derive a good characterization of the majority of solutions:

• Subject Matter: The most obvious way to describe a solution is to examine its content, structure, and function (i.e., its subject matter). Additionally, the solution may be described by examining the boundary of the solution and all the external factors that interact with the solution at the solution boundary (e.g., pre-conditions, post-conditions, consumers, suppliers, ownership, operation, influencing factors).
• Time: All solutions exist for a period of time. The subject matter and environment of a solution are likely to fundamentally change over time, so identifying the time period of a solution is a key contextual factor to consider. Additionally, when future solutions are being described, often the time period of the solution represents a target realization date and is used to plan and organize change activity.
• Maturity/Volatility: The extent to which the subject matter and environment of a solution are likely to change over time. Highly volatile or immature solutions are likely to be managed and valued very differently to very stable or mature solutions (e.g., flexible solutions are more valuable in volatile environments).

Characteristics of Architectures

Architectures are representations of particular solutions. As representations rather than actual solutions, architectures possess specific characteristics in addition to those described for solutions:

• Subject Matter: Architectures describe specific solutions and consequently inherit the objective characteristics of the solution that they represent (i.e., the subject matter, environment, time, and volatility).
• Viewpoint: The architectural domains considered and specific artifacts produced will provide a partial representation of the solution based on the needs of stakeholders. This viewpoint may be general, or specific to a particular architecture domain (i.e., business, data, application, and technology) or other consideration (i.e., Security, Operational Management, Integration, Construction, etc.).
• Level of Detail: The level of detail used to represent a solution has a strong influence on how an architecture can be used. Generally, less detailed architectures are more effective in communicating an overall solution approach, but less effective in supporting its realization.
• Level of Abstraction: A consideration for architecture characterization is how abstracted the architecture is from the solutions that it represents. For example, some architectures provide a direct description of a solution and others may describe an approach or pattern that is used across many solutions.
• Accuracy: Any architecture is a representation of reality and is not necessarily a completely accurate description of the intended solution. Typically, the level and quality of resource invested in the creation of an architecture will determine the accuracy of the result.

Applying Classification to Create Partitioned Architectures

The characteristics outlined in the previous section provide a comprehensive mechanism to describe and classify both architectures and solutions. Once these characteristics have been defined, they can then be used to partition and organize the Enterprise Continuum into a set of related solutions and architectures with:

• Manageable complexity for each individual architecture or solution
• Defined groupings
• Defined hierarchies and navigation structures
• Appropriate processes, roles, and responsibilities attached to each grouping

The following table shows how each classification criteria can be used to support partitioning of solutions:

The following table shows how each classification criteria can be used to support partitioning of architectures:

In practical terms, architecture discipline is used to support a number of different types of architecture that are used for different objectives. The classification criteria described above can be used in different ways to support the achievement of each objective.

Partitioning the Architecture Landscape to Understand the State of the Enterprise

Typically architectures are used to provide summary views of the Architecture Landscape (i.e., the state of the enterprise) at particular points in time. The following characteristics are typically used to partition the Architecture Landscape:

• Subject Matter: The subject matter area is generally the primary organizing characteristic for describing an Architecture Landscape. Architectures are functionally decomposed into a hierarchy of specific subject areas or segments.
• Level of Detail: With broader subject areas, less detail is needed to ensure that the architecture has a manageable size and complexity. More specific subject matter areas will generally permit (and require) more detailed architectures.
• Time Period: For a specific subject matter and level of detail an enterprise can create a Baseline Architecture and a set of Target Architectures that stretch into the future. Broader and less detailed architectures will generally be valid for longer periods of time and can provide a vision for the enterprise that stretches further into the future.
• Viewpoint: For a particular subject area, level of detail, and time period the stakeholders for architecture will have requirements to see architectures that address particular issues or viewpoints.
• Accuracy: Finally, each architecture view will progress through a development cycle where it increases in accuracy until finally approved. After approval, an architecture will begin to decrease in accuracy if not actively maintained. In some cases recency may be used as an organizing factor for historic architectures.

The following characteristics are generally not used to partition an Architecture Landscape:

• Architectures used to describe the Architecture Landscape are generally not abstract.
• Solution volatility generally prevents architectures from being defined that are far in the future. Volatility also reduces the accuracy of historic architectures over time, as the organization changes and adapts to new circumstances.

Using the criteria above, architectures can be grouped into Strategic, Segment, and Capability Architecture tiers, as described in Architecture Landscape.

Summary Classification Model for Architecture Landscapes shows a summary of the classification model for Architecture Landscapes.

In the same way that this classification model can be applied to the Architecture Landscape, it is also possible to apply a similar classification model to the Solutions Continuum (which is a collection of all the solutions that are represented by architectures) as shown in Summary Classification Model for Solutions .

Partitioning Reference Models to Encourage Good Practice and Re-Use

Architectures that describe particular solution approaches, best practices, or patterns can be developed (or acquired) and shared across the enterprise as reference models. The following characteristics are typically used to partition architecture reference models:

• Level of Abstraction: Because reference models aim to be abstract, re-usable solution approaches that can be adopted in many circumstances, the level of abstraction is generally a good starting place for organizing reference models. Highly abstracted models may be applicable to all enterprises. As these models become more specific they may only be relevant to certain types of system, certain industries, or even be specific to a single enterprise or line of business.
• Subject Matter: Within a particular level of abstraction several related models may address a particular theme or topic and therefore partitioning according to subject matter allows for ease-of-reference.
• Viewpoint: For any given subject, a number of reference models may address that subject from different complementary viewpoints. Related viewpoints can be grouped together to provide a richer understanding of the desired approach.

The following characteristics are generally not used to partition architecture reference models:

• Reference models are typically quite specific to a particular problem, with detail levels that are appropriate to show the desired approach. Reference models generally do not provide a graded breakdown into subsequent levels of detail.
• Accuracy, maturity, and stability are generally pre-requisites for an architecture to be considered a reference model.
• Because reference models are generally abstract and are not explicitly tied to deployed solutions, their time period is not relevant or difficult to manage in a structured form.

Using the criteria above, reference models can be grouped into four categories:

1. Foundation Architectures are very abstract reference models that could be applied to all enterprise architectures or solutions.
2. Common Systems Architectures show patterns and approaches for common systems that occur across many enterprises and industries, such as Enterprise Resource Planning (ERP) systems.
3. Industry Architectures provide shared blueprints that can apply to many partners or competitors within a single industry.
4. Organization-Specific Architectures provide common reference models that are specific to the enterprise, but still can apply across several business areas.

A summary of the classification model for architecture reference models is shown in Summary Classification Model for Architecture Reference Models .

Enforce Corporate Policy though Compliance with Standards

Organizations will generally attempt to encourage desired approaches and behaviors by defining and mandating a set of standards. The following characteristics are typically used to partition architectural standards:

• Viewpoint: As the intent of standards is to encourage consistent and desirable behaviors across the enterprise, it is typical to use "horizontal" viewpoints as a primary basis for partitioning standards. The architecture domains of business, data, application, and technology are common starting points, although other specific viewpoints, such as security, may exist in their own right.
• Subject Matter: Within a particular viewpoint, related standards can be grouped by subject matter.
• Maturity/Volatility: The maturity of a standard can be used to dictate its lifecycle stage. Immature standards can be marked as such and would typically carry a lower level of endorsement from the enterprise. As standards become mature, compliance with the standard is expected. As standards approach obsolescence, their usage is deprecated.

The following characteristics are typically not used to partition architectural standards:

• Standards are applied according to their maturity and generally not for specific time periods.
• Standards need to be detailed enough to assess compliance and are therefore not typically partitioned according to level of detail.
• Standards need to be concrete and specific enough to assess compliance and are therefore not typically partitioned according to level of abstraction.
• Standards are assumed to be accurate.

Using the criteria above, architecture standards can be grouped into four categories:

1. Business Standards relate to standard practice in the Business Architecture domain, including standard processes, roles, responsibilities, organization models, etc.
2. Data Standards relate to standard practice in the Data Architecture domain, including standard data models, data governance models, etc.
3. Application Standards relate to standard practice in the Application Architecture domain, including standard applications, application types, and application functionality.
4. Technology Standards relate to standard practice in the Technology Architecture domain, including standard products, product types, and proper usage constraints for technologies.

A summary of the classification model for architecture standards is shown in Summary Classification Model for Architecture Standards .

The ADM provides a process that is well suited to the application of a partitioned architecture approach:

• The Preliminary phase supports the identification of appropriate architecture partitions and establishment of governance relationships between related architecture partitions.
• ADM Phases A to F allow definition of the architecture within a specific partition.
• ADM Phases G and H allow the implementation of an architecture to be governed. This governance may apply to the direct realization of a solution, or may address the governance of architectures being developed in other partitions.

The following subsections provide more detailed guidance on how a partitioned architecture approach can be applied within the ADM.

Activities within the Preliminary Phase

One of the key objectives of the Preliminary phase is to establish the "architecture footprint" for the enterprise. In practical terms this activity will require the establishment of a number of architecture partitions, with defined boundaries and ownership.

Generally speaking, each team carrying out architecture activity within the enterprise will own a number of partitioned architectures and will execute the ADM to define, govern, and realize their architectures.

If more than one team is expected to work on a single architecture, this can become problematic, as the precise responsibilities of each team are difficult to establish. For this reason, it is preferable to apply partitioning to the architecture until each architecture has one owning team.

Finally, it is worth considering the distinction between standing capabilities of the enterprise and temporary teams mobilized to support a particular change initiative. Although the remit of standing teams within the enterprise can be precisely defined, it is more difficult to anticipate and specify the responsibilities of (possibly unknown) temporary architecture teams. In the cases of these temporary teams, each team should come under the governance of a standing architecture team and there should be a process within the ADM cycle of these teams to establish appropriate architecture partitioning.

Steps within the Preliminary phase to support architecture partitioning are as follows:

• Determine the organization structure for architecture within the enterprise: The various teams that will create the architecture should be identified. For each of these teams, appropriate boundaries should be established, including:
  • Governance bodies that are applicable to the team
  • Team membership
  • Team reporting lines
  • Whether the team is a standing capability or a temporary change team
• Determine the responsibilities for each architecture team: For each architecture team, the responsibilities should be identified. This step applies partitioning logic to the enterprise architecture in order to firstly identify the scope of each team and secondly to partition the architecture under the remit of a single team. Once complete, this step should have partitioned the entire scope of the enterprise and should have assigned responsibility for each partitioned architecture to a single team. Partitioning should create a definition of each architecture that includes:
  • Subject matter areas being covered
  • Level of detail that the team will work at
  • Time periods to be covered
  • Stakeholders
• Determine the relationships between architectures: Once a set of partitioned architectures has been created, the relationships between architectures should be developed. This step allows governance relationships to be formalized and also shows where artifacts from one architecture are expected to be re-used within other architectures. Areas of consideration include:
  • Where do different architectures overlap/dovetail/drill-down?
  • What are the compliance requirements between architectures?
  • Start each team running their own instance of the ADM

Once the Preliminary phase is complete, the teams conducting the architecture should be understood. Each team should have a defined scope and the relationships between teams and architecture should be understood. Allocation of teams to architecture scope is illustrated in Allocation of Teams to Architecture Scope .

Activities within Phases A to F

Within ADM Phases A to F an architecture team will create an architecture that addresses a specific scope of work. The focus within these phases is on content creation, and occurs at three levels:

• Architecture Vision: The Architecture Vision is developed within Phase A of the ADM. The Architecture Vision provides a high-level, informal view of the Target Architecture. Depending on the scope and requirements of the architecture, the Architecture Vision may provide a target for implementation, or may represent a view of the future that is well beyond current implementation plans, but serves as a directional guideline to assist in architectural planning and decision-making. For example, a ten-year vision for customer services capability would allow architects to see likely future developments and the long-term goal, but would not be directly implemented within a single project.
• Architecture Definition: The Architecture Definition is developed within Phases B, C, and D of the ADM. The Architecture Definition provides a formal model of the Baseline Architecture, Target Architecture, and gaps between the two states. The Architecture Definition may address the entirety of the Architecture Vision, or may select a tactical subset for consideration. As with the Architecture Vision, not all of the Architecture Definition needs to be immediately implemented. The Architecture Definition may, for example, outline a multi-phase roadmap to reach a long-term Target Architecture.
• Transition Architecture: Transition Architectures are developed within Phases E and F of the ADM. A Transition Architecture considers a range of activities that will be directly realized within a single change initiative. The Transition Architecture takes a Baseline and Target Architecture definition as the start and end points and considers the practical steps required to transition from one state to the next.

Considering architectures at the three levels of abstraction described above has a number of advantages, not least of which is the ability to carry out continuous architecture development, or "just in time" architecture.

Under this model, a long-term vision is established. A set of milestones are defined to achieve the vision, with architectures defined for the first key steps. The initial wave of implementation is then specified in detail through a Transition Architecture. As implementation of the initial Transition Architecture progresses, it can be governed against the Architecture Vision and Architecture Definition. Subsequent transitions can be defined in parallel with the implementation of the initial transition. As implementation progresses, the Architecture Vision and Architecture Definition can be refined using new information.

Using the "just in time" technique, architecture is only developed when it is needed, but implementation activity is still guided by a strategic vision and change roadmap.

Steps within the Architecture Vision phase to support architecture partitioning are as follows:

• Use the relationships between architectures defined in the Preliminary phase as a starting point; collect inputs from feeding architectures.
• Using the architecture boundaries defined in the Preliminary phase as a starting point, establish the scope of this ADM cycle:
  • Level of detail, subject matter, and time period for the Architecture Vision
  • Initial expectations for detail, subject matter, and time period to be covered in the Architecture Definition, including segmentation to be used (e.g., Are there different domain architectures? Are there different architecture states or milestones to be considered?); generally, the Architecture Definition should address a subset of the coverage of the Architecture Vision
  • Initial expectations for subject matter and time period to be covered for the first wave of implementation
• Establish the relationships between the architecture and the operational impact of the architecture. Use this to determine appropriate stakeholders.
• Define an Architecture Vision, including appropriate reference models from other architectures.
• Identify follow-on architectures that will be needed and define the hand-off points.
• For each follow-on architecture, determine whether this team will create the architecture in a subsequent ADM cycle, or whether a different team will take on the development work.
• Extract appropriate re-usable content for integration or use as reference models elsewhere.

Steps within the Business Architecture, Information Systems Architecture, and Technology Architecture phases to support architecture partitioning are as follows:

• Use the scope of the Architecture Vision as a starting point and select which areas of the vision will be elaborated in more detail.
• Develop (more) formal models of the solution, including appropriate reference models from other architectures. This could be for the entire scope of the vision, or for a subset of the vision.
• For each state/milestone to be addressed, define the Baseline Architecture, Target Architecture, and gaps.
• Extract appropriate re-usable content for integration or use as reference models elsewhere.

Steps within the Opportunities & Solutions and Migration Planning phases to support architecture partitioning are as follows:

• Define appropriate Transition Architectures, including appropriate reference models from other architectures.
• Re-visit the states and milestones of change identified in the Architecture Vision and Architecture Definition, based on an understanding of feasibility, viability, priority, and dependency. Circle back if needed to create a new Architecture Vision or set of Architecture Definitions.
• Define scope and terms of reference for out-of-context, detailed work. This work may involve doing architecture, or may be restricted to directly delivering a change solution that complies with the architectures that were developed.
• Extract appropriate re-usable content for integration or use as reference models elsewhere.
• Start up out-of-context, detailed work.

Development of an Architecture Vision, Architecture Definitions, and Transition Architectures is illustrated in Development of Architectures .

Activities within Phases G and H

Within Phases G and H the architecture team will oversee the realization of the architecture. Oversight of the architecture realization is through Implementation Governance (assessing compliance of realization efforts against the architecture) and Architecture Change Management (reacting to situations where the realization efforts do not and cannot comply with the architecture). Ultimately the architecture will be transitioned into operations and will become part of the new baseline of the enterprise.

Where architecture realization occurs through the definition of further, more detailed (i.e., out-of-context) architectures developed by other teams, these architectures should reside within separate partitions and the governance relationships between the architectures should be captured within the partitioning model.

Content Aggregation and Integration

Creation of a number of partitioned architectures within an enterprise runs the risk of producing a fragmented and disjointed collection of architectures that cannot be integrated to form an overall big picture.

In order to mitigate against this risk, standards for content integration should be defined and architecture governance should address content integration as a condition of architectural compliance. Content frameworks, such as the TOGAF content framework (refer to Part IV: Architecture Content Framework) can be used to specify standard building blocks and artifacts that are the subject of content integration standards.

For example, a standard catalog of business processes can be agreed for an enterprise. Subsequent architectures can then ease integration by using the same process list and cross-referencing other aspects of the architecture to those standard processes.

Content aggregation and integration can be addressed from a number of dimensions:

• Integration across the architectural domains provides a cross-domain view of the state of a segment of the enterprise for a point in time.
• Integration across the organizational scope of the business provides a cross-segment view of the enterprise.
• The Architecture Vision provides an integrated summary of Architecture Definitions, which provide an integrated summary of Transition Architectures.

Architecture Content Aggregation shows how architectural content can be aggregated using a variety of techniques.